f4: Facebook's Warm BLOB Storage System
osdi14のfacebookと愉快な仲間たちによる論文
これ以前のBLOBストレージはデータがデカかったので、同じ信頼性を保ちつつreplication factorを3.6から2.8-2.1に削減した
avashe.iconf4はhotではなくwarmなストレージ
信頼性を確保しつつ数日から数時間ごとに取得リクエストがくるくらいを想定している
要件に違反しない程度の速度を維持しつつ、可能な限りシステムへの負荷とreplication factorを削減する
f4の構成
BLOB群はセルという単位で保管
レプリケーションは3つ
セルは分散erasure codingで補強
ディスク、マシン、ラック単位障害への対応
複数のラックにまたがりReed-Solomon(10,4) codingを採用
データセンター単位障害への対応
XOR codingを採用
それぞれ別のデータセンターにあるAとBのデータのXORを更に別のデータセンターに保管すると、片方が落ちても片方を復元できて、かつレプリケーションコストも半分で済む
読む経路と書き込み経路が異なる、図は論文のFigure 1参照
読み書き双方共にGraph Storeを見にいく
Graph Storeにはストレージのインデックスが構成されており、BLOBの保存先URLがわかる
BLOBに対する読み込みリクエストはCDNで防弾され、必要であればオリジナルのBLOBストレージに伝搬する
書き込みは普通にストレージを書き換えた後、Graph Storeを変更する
温度(あるBLOBにおけるリクエスト頻度)も測っている
一般に年齢(BLOBが登録されてからの期間)が伸びるほど、温度は減少していく
コンテンツの種類に応じて度合いが異なる
基本的に写真が減少しづらい
なんか8ヶ月くらいで動画が再浮上している
複数種類があるので分析はFigureを見てね
99%tileでBLOBへのアクセスが10IOPS/TBを下回るものがあるか見てみる
画像は一年経過しないと下回らない
それ以外は一週間立たずに下回る
動画やMessage(facebookのチャットツールであってる?)の添付ファイルなど
20 IOPS/TBくらいをhotからwarm向けのリーズナブルなストレージに移せることがわかった